Gateway Service Platform

ABSTRACT

A gateway service platform is disclosed that provides access to a payment processing system via an open network such as the internet. The gateway service platform also provides access to service systems that provide a variety of services and applications offered by or affiliated with the payment processing system. The gateway service platform allows the payment processing system to reach users and to facilitate transactions on a wide variety of devices that may not otherwise be able to connect to payment processing system. Other devices, such as payment terminal devices, can also interact with a payment processing system through the gateway service platform using the same network and protocol. Embodiments of the invention allow devices on these open networks to connect with the payment processing system without having to change the existing infrastructure of the payment processing system.

CROSS-REFERENCES TO RELATED APPLICATIONS

The present application claims the benefit of priority under 35 U.S.C.§119 from U.S. Provisional Patent Application Ser. No. 61/056,736,entitled “IP Gateway Platform,” filed on May 28, 2008, the disclosure ofwhich is hereby incorporated by reference in its entirety for allpurposes.

BACKGROUND

The present application discloses systems and methods that improve thedistribution capabilities, the ease of development, and the integrationof services and applications associated with a payment processingsystem.

Services and applications associated with a payment processing systemhave traditionally been implemented using a “Silo Framework.” In a SiloFramework, each service and application independently implements eachlayer of the service and each service individually integrates with thepayment processing network. For example, each service or applicationimplemented using a Silo Framework uses their own firewall layer,database layer, and connection interfaces to the internet,telecommunication networks, and payment processing networks.

Many inefficiencies exist when using a Silo Framework to implementservices and applications. As services and applications are developedpiecemeal over time, each independently implemented layer of a silocreates unnecessary redundancy between the services and applications.For example, each service may maintain its own firewall, databaseresources, and other modules used to provide the service. Thisphenomenon occurs even if multiple layers of the silos accomplish thesame basic function for each service and application. Not only is thisan efficient use of development resources, but it also makes it moredifficult to effectively integrate various services and applications.Additionally, differences between various implementations of the layersinevitably develop over time. As a result, there is often no singlecommon interface that devices can use to access these various servicesand applications. Consequently, it is more difficult for new services tobe developed and adopted by users. It is also more difficult tointegrate various services because there is no common way that all ofthese services carry out common tasks. As a result, implementing newcombinations of various services can be difficult and potentiallytime-consuming.

Another related problem that with the Silo Framework is that when asingle change to more than one service is to be made, each service mayhave to have its infrastructure individually modified. For example, ifsome services want to adopt support for a new technology, then eachaffected service would have to make the necessary adjustments toaccommodate the new technology. This becomes quite burdensome as thenumber of affected services grows. As a result, the process of updatingand maintaining services may become slower and potentially may nothappen at all.

Yet another problem with the Silo Framework is that it becomescumbersome to expand access to a payment processing network to a widevariety of access points, because each service or application has to beindividually configured to support each new means of access.Historically, this problem has not been much of an issue, because accessto a payment processing system has typically been controlled by alimited number of processing parties that act as the gatekeepers to thepayment processing system. These processing parties work with issuersand acquirers to provide access to a payment processing system andgenerally use a dedicated network connection to access the paymentprocessing system.

Over time, all of these inefficiencies have become more significant. Notonly has the number of new services, applications, and featuresincreased over time, but there is also a growing need to be able toaccess these services and applications over channels beyond the onescontrolled by the limited number of processing parties. As the number ofservices and applications increase along with the number of channelsused to access these services, the inefficiencies of the Silo Frameworkbecomes more and more significant. As a result of all of this, a newframework is needed to provide access to a payment processing system andto provide various services and applications associated with paymentprocessing systems.

These problems, as well as other problems, are addressed by embodimentsof the present invention.

SUMMARY

Systems and methods for improved methods and payment processing systemsare disclosed.

According to one embodiment, a gateway service system is used to provideservices related to an account held by a user. The gateway servicesystem comprises a number of different components or subsystems. Onecomponent is a gateway tier configured to communicate with devices overone or more open networks. Additionally, the gateway service system hastwo or more service systems, wherein the two or more service systems arecommunicatively coupled to the gateway tier and wherein the two or moreservice systems are configured to communicate with devices over the oneor more open networks via the gateway tier. The two or more servicesystems are also configured to communicate with a payment processingsystem. The two or more service systems are further configured toprovide a plurality of services related to an account held by a user.The plurality of services is provided to users using devices connectedto the one or more open networks. According to some embodiments, the twoor more service systems are integrated with each other in a way toprovide new functionality for one or more of the integrated services.

According to another embodiment, a method for providing services relatedto an account held by a user is disclosed. The first step of this methodinvolves receiving at a gateway provided by a server computer a requestfrom a device to access a service, wherein the request is received anopen network. Next, the request is sent to a service system provided bya server computer. The service system is one of a plurality of servicesystems communicatively coupled to the gateway. The service system isalso communicatively coupled to a payment processing system andconfigured to provide a one or more of services related to an accountheld by a user. Finally, a response is sent from the service system tothe device. According to some embodiments, one or more of the pluralityof service systems are integrated with each other to provide newfunctionality for one or more of the integrated services. Additionally,the above-described method can be embodied as control logic residing ona computer-readable medium so that a computer with a processor canexecute the steps of the method.

Further details regarding embodiments of the invention are providedbelow.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 illustrates exemplary services that can be implemented using agateway service platform according to an embodiment of the presentinvention.

FIG. 2 illustrates an embodiment of the present invention.

FIG. 3 illustrates an embodiment of the present invention.

FIG. 4 illustrates the dataflow for a challenge-response serviceaccording to one embodiment.

FIG. 5 illustrates a request for a P2P payment to be made according toone embodiment.

FIG. 6 illustrates the validation of a P2P request according to oneembodiment.

FIG. 7 illustrates the processing of a P2P request according to oneembodiment.

FIG. 8 illustrates the dataflow for a campaign push service according toone embodiment.

FIG. 9 illustrates the dataflow for a campaign pull service according toone embodiment.

FIG. 10 illustrates the dataflow for a events service according to oneembodiment.

FIG. 11 illustrates the dataflow for a card alert service according toone embodiment.

FIG. 12 illustrates the dataflow for a card alert service according toone embodiment.

FIG. 13 illustrates the dataflow for a card alert service according toone embodiment.

FIG. 14 illustrates the dataflow for a card alert service according toone embodiment.

FIG. 15 illustrates the dataflow for a ATM Locator service according toone embodiment.

FIG. 16 illustrates the dataflow for an IP Terminal service according toone embodiment.

FIG. 17 illustrates the dataflow for a passive enrollment serviceaccording to one embodiment.

FIG. 18 shows a diagram of an exemplary payment processing system.

FIGS. 19(A) and 19(B) show diagrams of exemplary portable consumerdevices.

FIG. 20 shows a diagram of an exemplary system that can be usedaccording to various embodiments.

DETAILED DESCRIPTION

One embodiment of the invention uses a gateway service platform toprovide access to a payment processing system via an open network suchas the internet. The gateway service platform also provides access toand helps integrate service systems that provide a variety of servicesand applications offered by or affiliated with the payment processingsystem. The gateway service platform allows the payment processingsystem to reach users and to facilitate transactions on a wide varietyof devices that may not otherwise be able to connect to paymentprocessing system. For example, one embodiment of the invention allowsweb-based and mobile-based devices to use the internet and InternetProtocol (IP), as the network and communication protocol respectively,to connect to the payment processing system without using the servicesof a processing party. Other devices, such as payment terminal devices,can also interact with a payment processing system through the gatewayservice platform using the same network and protocol. Gateway serviceplatforms can take incoming requests from devices over a network andpass the request on to a payment processing system for processing.Gateway service platforms can then take the response from the paymentprocessing system and deliver the response back to the device. Thisembodiment of the invention allows the devices on these open networks toconnect with the payment processing system without having to change theexisting infrastructure of the payment processing system.

Embodiments of the gateway service platform can also help integratevarious services and applications so that new functionality can beconsistently and quickly implemented by services and applications. Forexample, services that push alerts or other notifications, such as anactivity alert service or a balance notification services, can beintegrated with each other so that users can configure a common set ofpreferences for how these services can push information out to the user.Additionally, these services can use a common interface or protocol forpushing information out to users. Services that may wish to implementnew features that push information out to users, such as a P2P Service,a couponing service, or other services, can integrate with thenotification infrastructure created by services such as an activityalert service to more quickly and efficiently implement new features.

Another embodiment of the invention uses multiple gateway serviceplatforms located at various locations around the world to provideaccess to a payment processing system. These gateway service platformsalso provide access to the service systems that provide services andapplications offered by or affiliated with the payment processingsystem. Additionally, each gateway service platform can serve deviceslocated in a large geographic area. The gateway service platforms canalso be used to provide redundancy in the network so that the networkcan better handle failures that may occur at a given gateway.

Embodiments of the invention allow for a number of improvements over theprior systems and methods used to access payment processing systems andtheir related services and applications. One improvement offered by theembodiments of the invention is that the various services andapplications offered by a payment processing system have a unified andcommon means for providing access to their services via a commonlyavailable network such as the internet. As new services and applicationshave been added over time, they have often been developed independentlyof each other. As a result, if and when these new services andapplications develop the ability for devices to access portions of theservices over networks such as the internet, each service or applicationbuilt their own independent infrastructure to support such access. Thisindependent development not only creates unnecessary redundancy ofbackend systems, but also results in many different interfaces andprotocols for accessing the services and applications. Embodiments ofthe present invention improve this situation by offering a unified meansfor providing access to the various services and applications offered bypayment processing systems. Embodiments of the invention also allow forquick and easy access to services over commonly used networks.Additionally, a more unified implementation of services and applicationsmakes it easier to integrate services and applications to take advantageof potentially synergetic relationships between offered services andapplications.

Another improvement offered by embodiments of invention is easier accessto a payment processing system and its related services andapplications. Embodiments of the invention offer easier access by usingcommonly available networks and technologies, such as the internet andIP. Prior systems and methods for accessing payment processing systemsoften required parties, such as merchants, to configure special accessto an otherwise closed network. For example, merchants wishing to accessa payment processing system would typically need a special connectionsetup and configured so that the merchants could process transactionsusing the payment processing system. Embodiments of the gateway serviceplatform allow for merchants to process transactions using a paymentprocessing system via a standard internet connection that is easy tosetup and widely available. Additionally, access to any services orapplications associated with the payment processing system can also beprovided using the same widely available network connections.

Embodiments of the present invention improve on the above-describedproblems as well as offer other advantages as further described below.

I. Gateway Service Platform A. Unified Framework Overview

FIG. 1 illustrates an example of a logical framework according to anembodiment of the present invention. As described herein, the embodimentillustrated in FIG. 1 offers a robust, fortified, and secure deliverychannel for a variety of payment and non-payment services andapplications. The embodiment illustrated in FIG. 1 can support manydifferent channels. Such channels include internet channels, mobilechannels, and traditional brick and mortar channels.

Various services and applications 101 are shown at the top layer of thediagram illustrated in FIG. 1.

The services and applications 101 illustrated in FIG. 1 are furthergrouped according to a classification of the particular service. Systemgrouping 102 is shown with three types of services: Mobile Services, WebServices, and Terminal Services. A mobile service is an application thatusually uses a mobile device and a mobile network as the channel for theapplication. Example mobile devices include cell phones and PDA's. A webservice is an application that typically uses standard web browsers andthe internet. A terminal service is an application typically associatedwith a terminal used to process payment transactions in a retail storeor other similar setting. Other embodiments of the invention shown inFIG. 1 could easily be extended to support additional categories ofservices as needed.

Each of the systems represented in group 102 may use a different meansfor communicating with different devices. For example, a web service mayuse an internet connection provided by an Internet Service Provider(ISP) in order to connect to the gateway platform and a mobile devicemay be sent an SMS text message over a cellular network. Additionally,these various channels can sometimes overlap. For example, it is notuncommon for a mobile device to access the internet using a cellularnetwork.

Gateway Service Layer 103 receives a communication that has been routedto the Gateway Service Layer 103 from a web service, mobile service,terminal service at layer 102. Gateway Service Layer 103 may analyze thereceived communication and take an appropriate action. For example, theGateway Service Layer 103 may reformat the communication so that alegacy processing system can properly respond to the device that sentthe communication. The Gateway Service Layer 103 may also respond to thecommunication itself.

The Gateway Service Layer 103 illustrated in FIG. 1 is shown with avariety of elements such as: Value Added Services, Firewalls,Enrollment, Routers, Authentication, Payment Processing, Aggregators,and Cooperative Processing. Each of these elements can be implementedthrough a variety of server computers that help make up the GatewayService Layer 103. Additional details on these elements and how theseelements can help process communications from devices are providedbelow.

The final layer illustrated in FIG. 1 illustrates a connection layer 104that comprises connections to various networks, systems, or othermodules that may be external to the Gateway Service Layer 103. In someembodiments, the networks, systems, or modules connected to the GatewayService Layer through connection layer 104 are legacy networks orsystems. In the embodiment illustrated in FIG. 1, a legacy paymentprocessing system, such as VisaNet™, is connected to the Gateway ServiceLayer 103. Other payment processing systems could be used according toalternative embodiments. Gateway Service Layer 103 uses connection layer104 to conduct transactions, forward requests and responses, or passalong any other data generated from devices to payment processingsystems, merchants (via back office connectivity), or other connectednetworks or modules.

The capabilities offered by the embodiment illustrated in FIG. 1 allowsfor a number of additional advantages to be realized. For example, theembodiment illustrated in FIG. 1 allows for the easy creation of newconnection options for payment transactions. It is also possible toexpand the reach of payment processing systems to new paymentoriginators and customers. Value added services can be delivereddirectly to cardholders, merchants, buyers, suppliers, or any otherusers of a payment processing system. The embodiment illustrated in FIG.1 can easily integrate with new technology paradigms and Internet basedservices with open standards (e.g., XML). Additionally, the embodimentillustrated in FIG. 1 can integrate with existing payment processingsystems without re-tooling existing infrastructure in the paymentprocessing system and still maintain high levels of security,reliability, and redundancy. These capabilities arise, in part, becausethe Gateway Service Layer 103 is able to connect devices operating on afirst network to a payment processing system operating on a secondnetwork. Payment processing systems, such as VisaNet™, are typicallyaccessed using dedicated leased network lines that have beenspecifically configured to give access to the payment processing system.In other words, payment processing systems are typically accessed usinga closed network. Embodiments of the system illustrated in FIG. 1 removethis restriction and allow for these new capabilities to be realized byeliminating the technology and payment hurdles created by a legacyenvironment. Additionally, the embodiment illustrated in FIG. 1 allowsvarious services and applications to share common elements of theirinfrastructure. This makes it easier to integrate the services andapplications with each other. Additionally, this allows developers tomore easily leverage some of the services and applications to offerimproved capabilities for other services and applications.

B. Exemplary Embodiment

FIG. 2 illustrates an embodiment of the present invention.

As described in more detail later in this disclosure, consumer devices201 may be in any suitable form. For example, suitable consumer devicescan be hand-held and compact so that they can fit into a consumer'swallet and/or pocket (e.g., pocket-sized). They may include smart cards,ordinary credit or debit cards (with a magnetic strip and without amicroprocessor), keychain devices (such as the Speedpass™ commerciallyavailable from Exxon-Mobil Corp.), etc. Other examples of consumerdevices include cellular phones, personal digital assistants (PDAs),pagers, payment cards, security cards, access cards, smart media,transponders, and the like. The consumer devices can also be debitdevices (e.g., a debit card), credit devices (e.g., a credit card), orstored value devices (e.g., a stored value card). Other consumer devicesmay include personal computers, laptops, or other devices capable ofcommunicating over the internet.

As described in more detail later in this disclosure, access devices 210can be in any suitable form. Examples of access devices include point ofsale (POS) devices, cellular phones, PDAs, personal computers (PCs),tablet PCs, handheld specialized readers, set-top boxes, electronic cashregisters (ECRs), automated teller machines (ATMs), virtual cashregisters (VCRs), kiosks, security systems, access systems, and thelike.

In the embodiment illustrated in FIG. 2, both the consumer devices 201and access devices 210 are shown as being connected to the internet 205.In other embodiments of the invention, consumer devices 201 or accessdevices 210 may be connected to other networks. For example, in someembodiments these devices may be connected to a cellular network,satellite-based network, or any other suitable network for datacommunications. In some embodiments, consumer devices or access devicesmay connect to the internet via a second network, such as a cellularnetwork.

In the embodiment illustrated in FIG. 2, a security/authorization module215 sits between the internet 205 and a gateway service system 220. Insome embodiments, the security/authorization module 215 may compriseitems such as firewalls, load balancers, or any other programs runningon a server computer that can be used to protect a gateway servicesystem 220 from malicious attacks.

Gateway service system 220 is represented in FIG. 2 as comprising twodistinct classes of systems: a gateway 221 and various service systems222-225. The gateway service system 220 is further integrated with alegacy payment processing system 240. This integration allows thegateway service system 220 to offer services to consumer devices 201 andaccess devices 210 that may not normally be able to directly communicatewith the payment processing system 240. In some embodiments, the paymentprocessing system may not need to be modified in order to integrate withthe gateway service system 220.

Gateway 221 primarily serves as a mechanism for forwarding communicationfrom consumer devices 201 or access devices 210 to the appropriateservice system for the communication. Typically the gateway 221 willcomprise one or more server computers running software. According tovarious embodiments, a gateway 221 may accomplish its task in any numberof ways. For example, packets of data that are received from consumerdevices 201 or access devices 210 may contain information indicating theproper destination of the packet. In some embodiments, various consumerdevices 201 or access devices 210 may only be authorized to communicatewith particular service systems. One skilled in the art will recognizethat there are many other ways to properly route communications fromconsumer devices 201 and access devices 210 to the appropriate servicesystem. In some embodiments, multiple gateways may exist wherein eachgateway handles communications received from a different network. Forexample, one gateway may handle communications received over theinternet while another gateway may handle communication received over atelecommunication network.

Service systems, such as value added service system 222, authenticationservices 223, payment processing services 224, and cooperativeprocessing services 225, sit behind the gateway 221, and these servicesystems comprise server computers running modules that contain the logicfor the various services and applications that provide theirfunctionality in conjunction with a payment processing system. Asillustrated in FIG. 2, each of these service systems may be furthercomprised of additional subsystems. For example, valued added service222 is shown in FIG. 2 with subsystems 222(a) for a mobile notificationservice and 222(b) for a loyalty coupon service. Authentication service223 is shown with a Verified by Visa 2.0 service 223(a) and achallenge/response service 223(b). Payment processing services 224 isshown with a terminal driving service 224(a), eCommerce payment service224(b), and a money transfer service 224(c). Cooperative processingservice 225 is shown with a fraud scoring service 225(a). Otherembodiments may contain service systems other than the ones representedin FIG. 2, and many of these services, systems, and subsystems aredescribed in more detail later in this disclosure. Additionally, someembodiments may have additional systems that serve to support theservice systems. For example, a database server could interface withmultiple service systems to help those systems implement theirfunctionality.

The payment processing system 240 may include data processingsubsystems, networks, and operations used to support and deliverauthorization services, exception file services, and clearing andsettlement services. An exemplary payment processing system may includeVisaNet™. Payment processing systems such as VisaNet™ are able toprocess credit card transactions, debit card transactions, and othertypes of commercial transactions.

Payment processing systems, such as VisaNet™, typically include varioussub-systems that help the networks provide their services. For example,VisaNet™ includes an Integrated Payment System (IPS) 241, such as theVisa Integrated Payment System, which processes authorization requestsand a Base II system which performs clearing and settlement services.Other potential modules include:

-   -   An authorization interface for high volume retail transactions,        such as Visa Direct Exchange (DEX). These authorization        interfaces facilitate high-speed processing of payment        authorizations from devices such as credit cards;    -   Back Office Connectivity (B/O) that can provide functionality        such as security monitoring and real time help desk technical        support to merchants;    -   Debit Processing Service (DPS) 242 to provide comprehensive        processing support for check cards, credit cards, prepaid cards,        Interlink®, Visa/PLUS® ATM Network, POS Check Services, and        various ePay applications. Additionally, a debit processing        service can provide full-functioning ATM terminal driving and        network gateways services;    -   An incentive network 243, such as the Visa Incentive Network, to        provide a full-service direct marketing program developed to        help merchants easily deliver relevant offers and coupons to a        targeted group of cardholders; and    -   Other modules may also be a part of a payment processing system,        such as point-of-sale reporting systems 245, billing reporting        systems 246, and other systems. Payment processing system 240 is        described in more detail later in this disclosure.

Connected to the payment processing system are various endpoints 250 inthe payment processing system such as issuers 251, acquirers 252, andmerchants 253. These endpoints are the traditional endpoints of apayment processing system, and each of these endpoints is discussed inmore detail later in this disclosure.

C. Gateway Service Clouds

According to another embodiment of the invention, there is not just oneinstance of a gateway service system, but there are many related gatewayservice systems that can each be used to offer access to a paymentprocessing system. Such an embodiment is illustrated in FIG. 3. Thisembodiment offers a redundant solution that can be delivered centrallyor locally throughout the world as market conditions dictate. Thesevarious gateway service systems may form “gateway service clouds” thatoffer broad access to a payment processing system. Devices can accessany of available gateway service systems, but devices will typicallyaccess the gateway service system that will provide the best service forthe device. For instance, a device will often use the gateway that isthe closest to the device. Closest may be in either a network sense orphysical sense. If device's first choice for a gateway isnon-responsive, the device can try to access more remote gateways.

In FIG. 3, there are three gateway service systems, system 301, system302, and system 303. These three gateway service systems each provideaccess to various payment processing system modules. In FIG. 3, twopayment processing system modules are represented. There is anintegrated payment system (IPS) 310 and a Direct Exchange (DEX) 320interface. These payment processing modules are connected to variousnetwork endpoints 330. As mentioned previously, such endpoints mayinclude issuers, acquirers, and merchants.

There are four regions represented in FIG. 3, regions 371-374. In otherembodiments there may be additional regions or fewer regions. Theregions may represent any logical division of an area that wishes to usethe gateway service systems to connect to the payment processing system.For example, the regions may present different geographical regions,such as North America, Latin America, Europe, Asia, etc. Alternatively,the regions may be divided by various network characteristics, such asIP address.

Within regions 371-374 are various consumer devices 340, merchantdevices 350, such as access devices, and perhaps other third partydevices 360 that wish to use a gateway service system to connect to apayment processing system. Any of these devices can use any of the threerepresented gateway service systems 301-303 to access the paymentprocessing system. Once a gateway service system has been selected by adevice, then the device can interact with a payment processing system inthe same manner as it would if there was only one gateway service systemavailable.

It should be understood that while this disclosure frequently referencesonly a single gateway service system when describing the features andfunctionality of the system, these descriptions are also applicable toembodiments that utilize gateway service clouds.

D. Exemplary Embodiments Enabling Various Services and Applications

Payment processing systems (sometimes referred to as payment processingnetworks) offer a variety of services and applications to users. Forexample, one of the primary services offered by payment processingsystems is a service that authorizes payment transactions. In additionto processing payment transactions, payment processing systems alsotypically have many other services provided to users of the system.Example services include applications such as: authenticationapplications, ATM locator applications, offers/couponing applications,activity alert applications, and balance notifications application.

Example services that can be used with various embodiments of thepresent invention have been previously described in a variety ofcurrently pending patent applications. Those patent applicationsinclude: U.S. patent application Ser. No. 11/962836 describing acustomized payment transaction notification application, U.S. patentapplication Ser. No. 11/963736 describing a real-time balance updateapplication, U.S. patent application Ser. No. 11/960162 describing acoupon application, U.S. patent application Ser. No. 11/960173describing a mobile coupon application, U.S. patent application Ser. No.11/536296 describing a mobile transit fare payment application, U.S.patent application Ser. No. 12/022060 describing a mobile device paymentapplication, and U.S. patent application Ser. No. 11/794343 describing achallenge response application. All of these patent applications areherein incorporated by reference in their entirety for all purposes. Oneskilled in the art will recognize that there are many other potentialservices that can be integrated with a payment processing system in amanner similar to these disclosed references. Additionally, any of theseservices or any features thereof can be combined in any suitable manner.

FIGS. 4-17 illustrate how data might flow between consumers, merchants,and other users of a payment processing system according to variousservices and applications that can be offered according to variousembodiments. The embodiments illustrated in FIGS. 4-17 share many commoncomponents. Some of these components are described below.

Consumers 501 (sometimes referred to as “users” in this disclosure) areone set of end users of a gateway service platform 520. The consumers501 can communicate with the gateway service platform 520 directly overthe internet 510 or indirectly via a telecommunication network 502.Typically, consumers 501 will use a portable consumer device or otherelectronic communication means to communicate with the gateway serviceplatform 520. Similarly, a merchant 503 is another end user that maycommunicate with a gateway service platform 520 over the internet 510 ora telecommunication network 502. A merchant 503 may use an access deviceor other appropriate means to communicate with the gateway serviceplatform 520.

The gateway service platform 520 illustrated in FIGS. 4-17 is shown withthree separate tiers of subsystems: a gateway tier 521, an applicationtier 522, and a database tier 523.

Gateway tier 521 is similar to gateway 321 as discussed with referenceto FIG. 2. The embodiment of gateway tier 521 illustrated in FIGS. 4-17is shown with two distinct gateways. There is a web gateway 521(b) whichserves as a gateway for web-based communications received by the gatewayservice platform 520, and there is a telecommunications gateway 521(a)that can serve as a gateway for communications received over atelecommunication network. Other embodiments may also contain othergateways to provide the gateway service platform with access to otheropen networks.

Application tier 522 is shown in FIGS. 4-17 with an application server522(a) and a reporting server 522(b). Application tier 522, asrepresented in FIGS. 4-17, is one representation of a service systemrepresented in FIG. 2. An application server 522(a) may comprise aserver computer running software comprising the logic for a particularservice or application. Reporting server 522(b) can be used to generatereports, conduct analysis, or offer any other type of ancillary serviceassociated with the application server's service. Because FIGS. 4-17each illustrate the dataflow for an embodiment of one particular serviceor application, only one application tier 522 with one applicationserver 522(a) and one reporting server 522(b) is shown in FIGS. 4-17.However, as previously disclosed, a gateway service platform 520 willtypically offer many different services and applications. These servicesand applications may all be offered from a single application tier 522using many different servers, or there may be multiple application tierswithin an embodiment of a gateway service platform 520. Furthermore,many of these services and applications will be integrated with eachother to provide new functionality. Many of these services andapplications will often have integration points between them that maynot be represented in FIGS. 4-17.

Database tier 523 can be used within gateway service platform 520 tostore various pieces of information that are used to provide theservices, applications, and other reporting capabilities of theapplication tier 522. According to various embodiments, the databasetier can be used to store information for a plurality of differentservices and applications, and integrated services and applications mayaccess the same data structures stored in the database tier. In FIGS.4-17, the database tier is shown with a SQL server computer 523(a) andan associated data store 523(b). One skilled in the art will recognizethat other types of databases or similar means for storing data can beused in place of an SQL server computer.

Payment processing system 530, and the associated sub-components of thenetwork 531-537, are the same as payment processing system 340 shown inFIG. 2. For example, 531 is a payment system, such as the VisaIntegrated Payments system, 532 is a debit processing service, 533 is anincentives network, such as the Visa Incentives Network, 536 is apoint-of-sale reporting module, and 537 is a billing module.

Additionally, FIGS. 4-17 show various endpoints as appropriate for theparticular service or application being represented in the figure. Forexample, FIG. 7 illustrates an issuer payor 550 and an issuer payee 540transferring money between the payer and the beneficiary. Theseillustrated endpoints are the typical endpoints for a payment processingsystem 530. These endpoints will be described in more detail whereappropriate in the context of the particular service or applicationbeing discussed.

It should be noted that while the following descriptions of variousservices and applications can be used to implement the describedfunctionality, one skilled in the art will recognize that similarservices and functionality can be implemented using different data flowsand modules. The below descriptions are meant to be examples of how oneskilled in the art could implement a wide variety of services ofapplications using the gateway service platform.

1. Challenge/Response Authentication Service

FIG. 4 illustrates the dataflow for a challenge-response serviceaccording to one embodiment. U.S. patent application Ser. No. 11/794,343also describes a challenge response service and can be referenced foradditional information on such services.

Challenge/response services and applications are services that enablenew authentication solutions to be delivered for high-risk transactions.For example, card-not-present (CNP) transactions, such as transactionsconducted with a merchant over the internet, is one situation where achallenge/response service can be used to help prevent fraud.

Challenge/response services can go beyond simple username/passwordmechanisms. Usernames and passwords can be very burdensome for consumersbecause consumers frequently have multiple passwords for differentchannels and products and have to potentially memorize many differentpasswords. Additionally, consumers may be required to change passwordsover time for different services. Additionally, there can be differentlevels of ownership over a single account used to conduct a transaction(e.g., joint payment cards).

As a result of the potential difficulties encountered withusername/password challenge-response services, many different types ofchallenge-response systems have been developed. Many of these systems donot require enrollment before the challenge-response service can beused, and the degree of difficultly or the number of successfulresponses before a transaction is allowed can be adjusted based on therisk of a particular transaction. One example of a challenge-responsesystem is to require a consumer to enter the zip code associated withbilling address of portable consumer device. Other personal informationon record could also be used instead of the billing zip code. Anotherexample is that a user could be asked to respond with informationspecifically entered by the consumer at an earlier time (e.g., the modelof the consumer's first car, consumer's high school, etc.).

Another design consideration when implementing a challenge-responseservice includes avoiding complex transaction design and postintegration to payment systems. For example, a complex design of achallenge-response service for a transaction occurring over the webwould make it more difficult for the service to be implemented for eachweb retailer wishing to take advantage of the challenge responseservice.

In FIG. 4, an example challenge-response service implemented using thegateway service platform is illustrated.

At step 4(1), a consumer 501 checks out with a merchant 503. In oneembodiment, the merchant 503 is an online merchant. The consumer 501checks out by indicating that the consumer 501 is ready to purchase oneor more items that have been placed in a shopping basket on themerchant's 503 website.

At step 4(2), the merchant 503 sends the information contained in theconsumer's shopping basket to the application server 522(a) located inthe gateway service platform 520. In the embodiment illustrated in FIG.4, this information first passes through the web gateway 521(b) beforearriving at the application server 522(a). The web gateway 521(b) mayanalyze the information arriving from the merchant 503 to ensure thatthe communication arrives at an application server that offers achallenge-response service.

At step 4(3) a challenge is presented directly to the consumer 501. Thechallenge can be generated based on information received from themerchant 503. For example, the consumer 501 would have already enteredthe account information for the payment device to be used to conduct thetransaction. This information can be used to select the appropriatechallenge to be presented to the consumer 501. In one embodiment, theinformation used to create the challenge may be present within theapplication tier 522 or the database tier 523. In other embodiments, theapplication server 522(a) may request information from the paymentprocessing system 530 in order to create the challenge. Additionally,other information, such as the value of the items to be purchased, thetime of day of the transaction, or any other relevant information can beused to select the challenge presented to the consumer 501. The consumer501 then enters the response to the challenge, and the application tier522 then determines whether the response was correct.

At step 4(4), outcome of the challenge-response service is communicatedto the merchant 503. If the consumer 501 successfully passed thechallenge presented, the merchant 503 can process the transaction withthe knowledge that the consumer 501 has successfully complete thechallenge-response service offered by the gateway service platform 520.

2. Payment-To-Peer Service

FIGS. 5-7 illustrate the dataflow for a payment-to-peer (P2P) serviceaccording to one embodiment. A payment-to-business service would followa similar dataflow. FIG. 5 illustrates a request for a P2P payment to bemade according to one embodiment. FIG. 6 illustrates the validation of aP2P request according to one embodiment. FIG. 7 illustrates theprocessing of a P2P request according to one embodiment.

In the context of a P2P service, a consumer (the “payor”) may wish tosend money to another user (“payee”), and the payee may wish to receivethe money in the form of a deposit to an account that has been providedby an account issuer. As used herein, a “deposit” may include an actualtransfer of money to an account such as a debit card account, or mayinclude a debit to an account such as a credit card account. There aremany different types of accounts that can be issued, such as credit cardaccounts, debit card accounts, pre-paid card accounts, and gift cardaccounts. Generically, these accounts may be referred to as transactionaccounts, because they will typically provide the payee with the abilityto use the account to engage in financial transactions. This isgenerally accomplished through the issuance of a transaction card thatis associated with the transaction account. Transaction cards can takemany forms, including plastic cards with a magnetic stripe, smartcards,secure tokens, or any other suitable form. In other situations, thepayee may only have an account number which identifies the transactionaccount and can be used to perform transactions.

The payee may often have multiple transaction accounts that have beenissued by multiple issuers. As discussed herein, an issuer is often afinancial institution, such as a bank, that creates and maintainsfinancial accounts. Unlike traditional bank accounts, such as checkingand savings accounts, it is typically not possible for anyone other thanthe owner or authorized user of a transaction account to make depositsinto the transaction account. As an example, it is typically notpossible for anyone other than the owner or authorized user of a creditcard to make payments to the account associated with the credit card.This may be for the simple reason that to allow a third party to make apayment to a credit card would require revealing the accountinformation, such as the credit card number, to the third party.

There are many variations on the P2P service illustrated in FIGS. 5-7.For example, some embodiments may allow payees to send invoicesdetailing why a payment is requested from a payor. Other embodiments mayallow for users to send or receive payments without registering with theP2P service (“ad hoc” users). One skilled in the art will recognize thatmay other potential variations of a P2P service can be implement using agateway service platform 520.

In FIG. 5 at step 5(1), a user 501 makes a P2P payment request to thegateway service platform 520. In the example illustrated in FIG. 5, theuser 501 makes the request using a telecommunication network 502 thatprovides access to the internet 510. For example, the user 501 may makethe P2P payment request by sending a text message from a portableconsumer device such as a mobile phone. The telecommunication network502 routes this text message to the gateway service platform 520,wherein the Telco Gateway 521(a) routes the message to the appropriateapplication server 522(a). Other embodiments of a P2P serviceimplemented with a gateway service platform 520 may allow users to senda P2P payment request using a web-based interface, email, or any otherappropriate means.

At step 5(2), the received payment request is validated and augmented byaccessing data that may be stored within the database tier 523. Forexample, if the request was send by text message and indicated aparticular user account to be used for the transaction, the P2P servicecould verify that the portable consumer device that sent the request isauthorized to send P2P payment requests. Additionally, other informationthat might be needed to complete the request, such as the issuers of thefinancial accounts to be accessed during the transaction, can also beverified at this time. Various embodiments may also check the paymentrequest against various preferences or limits set by the payor andstored by the P2P service. For example, the payor may have set a paymentlimit for P2P requests.

Referring now to FIG. 6 at step 6(1), if a payment request is made bytext message, payor may receive an Interactive Voice Response (IVR) callback to validate the transaction. For example, the IVR callback mayrequest a mobile pin to be entered before continuing with thetransaction. This callback provides extra security for users who wish toinitiate a payment to an individual or business from a device such as amobile phone. Additionally, it may be possible to request additionalinformation from the payor at this time.

Referring now to FIG. 7 at step 7(1), the payment request, after asuccessful IVR call back, is handed to IPS 531 in a payment processingsystem 530 for processing. The payment processing system 530 may thenreceive, as a part of the payment request, the account informationprovided by the payor. The payment processing system also needs todetermine the issuer of the account to be used to make the payment. Inone embodiment, the issuer can be determined based on the accountnumber.

At step 7(2), IPS 531 orchestrates the payment between the properfinancial institutions. The issuer 550 of the payor's transactionaccount may receive a request for the transfer of funds. Typically thisrequest will contain account information and transaction information.After verifying that the account information is valid and thatsufficient funds or credit exists to make the payment, the payor issuer550 may respond to the payment processing system 530 and indicate thatthe transaction may proceed.

Upon receipt of the message indicting that the transaction may proceed,the payment processing system 530 may withdraw funds from the payor'saccount held with issuer 550. In one embodiment, the received funds maybe temporarily stored in a generic holding account at the paymentprocessing system 550 prior to being transferred to the issuer of thepayee's account 540. In another embodiment, the funds may be temporarilystored in a holding account that is associated with the issuer 540 ofthe payee's account, but not specifically associated with the payee'saccount.

The payment processing system 530 may then push the funds received fromthe payor's transaction account into the account specified by the payeein a payment request. The payment processing system 530 may send amessage to the issuer 540 of the payee's account requesting that thefunds received be transferred from the account in which they are beingheld temporarily, into the account that the payee has specified. Again,the payment processing system 530 is capable of this transaction becauseit contains payment authorization, clearing, and settlement services.After the funds have been deposited into the account specified by thepayee, the payee issuer 540 may send a response message to the paymentprocessing system 530 indicating the successful transaction.

At step 7(3), the payor and payee may be notified of the completion ofthe transaction. This notification may alert the parties that the fundshave been deposited into the specified account, and that the transactionis complete. In one embodiment, the notification may be in the form ofan e-mail. In other embodiments, the notification may be an instantmessage, a telephone message, a pager message, or the like. Furthermore,in some embodiments, after the transaction is complete, all records ofthe transaction may be purged from the system in order to provide anadditional measure of security and privacy to both the payor and thepayee.

Although the above example depicts a single issuer associated with asingle payee with a single account, it would be clear to a person ofskill in the art that this is not limiting. A payee may have any numberof accounts, issued by any number of issuers. Likewise, a payor may haveany number of accounts, issued by any number of issuers. Issuers maylikewise issue transaction accounts to any number of users. In someembodiments, the payor and payee may both have transaction accountsissued by the same issuer.

4. Campaign Push Service for Offers or Coupons

FIG. 8 illustrates the dataflow for a campaign push service according toone embodiment. U.S. patent applications Ser. No. 11/960,162, describinga coupon application and Ser. No. 11/960,173, describing a mobile couponapplication, can also be referenced for additional information oncampaign push services.

A campaign push service stores and optionally sends reward andpromotional offers to consumers. Offers or coupons may be sent in anyone of a number of different forms, including but not limited to a shortmessaging service (SMS) message, a SMS link, a multimedia messagingservice (MMS) message, or e-mail message. Alternatively, the couponscould be distributed utilizing a Near Field Communications (NFC) system.Such an embodiment would require the portable consumer device to beequipped with an NFC chip and programmed with a software application.The source of the near field signal providing the electronic couponcould be local kiosks, for example as present in a shopping mall. Analternative source of electronic coupons available utilizing such nearfield communication is the point of sale itself. Consumers can alsorequest to view promotional material stored within the system. Othersources are possible.

Typically, potential users enroll in the mobile coupon program using anenrollment webpage or other similar mechanism. At this time, relevantinformation is collected from the user. For example, in an enrollmentform supplied electronically a user, the prospective participant canprovide information such as the telephone number of their portabledevice, a security password, and preferences regarding the types ofmobile coupons that they wish to receive.

Participants in the program may be notified of particular events, forexample limited time promotions. According to certain embodiments, thecoupons can be targeted based upon a location based services (LBS)approach, utilizing prior purchasing activity by a consumer as detectedover a payment processing system. For example, when the user swipes acard at a point-of-sale (POS), an authorization message is returned fromthe payment network which includes a Merchant Identification Number(MID). The user's location at that time of sale can be determined fromthe MID number.

Specifically, where a payment transaction is conducted over a paymentprocessing system, certain information is communicated that can be usedfor targeting of a mobile coupon. In particular, the very existence ofthe prior purchase transaction reveals the consumer to be activelyengaged in shopping rather than other activities (i.e. sleeping orworking). Based upon this timing information, the consumer is known tolikely be receptive to a mobile coupon for a subsequent transaction.Accordingly, embodiments of the present invention may thus generate anddisseminate a mobile coupon to the consumer within a predetermined,limited time period from receiving an indication from the paymentprocessing system that a prior payment transaction has occurred. Such anapproach allows for dissemination of a timely, non-intrusive mobilecoupons to the consumer.

The duration of effectiveness of such a mobile coupon can also belimited by time. Such an embodiment would provide an incentive for therecipient to monitor his or her portable device for receipt of a mobilecoupon, and use that coupon within the limited period that it iseffective. Moreover, in certain embodiments, upon expiration the mobilecoupon could be configured to automatically disappear from theconsumer's portable device. This would reduce intrusiveness of themobile coupon, as the consumer is not obligated to delete a backlog ofexpired coupons from his or her portable device.

Mobile coupons can also be targeted based upon a geographic location ofthe user as determined from the payment processing system. For example,the location of a consumer can be determined by analyzing the locationof the current base station through which the portable user device istransmitting and receiving information. The location of a consumer mayalso be determined by the use of Global Positioning System (GPS)technology.

Additionally, information regarding the nature of the prior purchaseconducted over the payment processing system can be referenced togenerate the coupon. Thus, a prior purchase of one product (for examplea vacuum cleaner), could lead to generation of a second product (bagsfor the vacuum cleaner). This coupon generation could be irrespective ofthe time or physical location of a prior purchasing transaction. Stillfurther alternatively, an LBS approach could be based upon the seller ofthe second product having an affinity agreement with the seller of theprevious product purchased.

Moreover, a mobile coupon may be generated based upon more than onepiece of information gleaned from a prior purchasing transactionconducted over a payment processing system. Specifically, the time,geographic location, and/or nature of the prior purchase transactioncould be combined to generate the targeted coupon.

Coupons may also be generated based on the accrual of a certain volumeof purchases utilizing a particular payment card not typically availableto other participants in the mobile coupon program. This targetedelectronic coupon is then communicated to the consumer's mobile devicefor redemption.

Many other potential campaigns are possible using the gateway serviceplatform.

Referring to FIG. 8 at step 8(1), a campaign file is provided to thegateway service system 520. In FIG. 8, the incentive network 533 pushesthis campaign file to the gateway service system, but the campaign filemay also be received from another component of the payment processingsystem 520 or manually staged from another source, such an issuer. Thiscampaign file contains the parameters and rules of the campaign, such asthe any of the parameters or rules described above.

At step 8(2), the offers are stored within the database tier 523. Thisallows for later web access of the offers by users/consumers 501. When aconsumer 501 later accesses a stored coupon, this is sometimes referredto as a campaign pull. The dataflow used for a campaign pull isdiscussed in more detail in relation to FIG. 9.

At step 8(3), offers that are to be sent are pushed out to theirdestination. In the embodiment illustrated in FIG. 8, the offer ispushed out through the telecommunication gateway 521(a) over atelecommunication network 502. This data flow would be applicable to adataflow pushed out using an SMS text message. Other embodiments thatpush offers using other means, such as e-mail, may use a slightlydifferent data path. As discussed above, the offers can also be pushedout to nearby access devices, nearby ATM, etc.

According to some embodiments, an aggregator will secure sufficientbandwidth for all of the expected messages may also be used to help pushout the offers to various consumers.

5. Campaign Pull Service for Offers or Coupons

FIG. 9 illustrates the dataflow for a campaign pull service according toone embodiment.

As previously discussed, a campaign pull service is closely linked witha campaign push service. After a coupon or other offer has been pushedto a consumer, the consumer may wish to store the offer for later userather than immediately redeem the offer. A campaign pull service allowsfor users to view, select, redeem, delete, ask for an offer to bere-sent, or take other actions on stored offers.

At step 9(1) in FIG. 9, a consumer 501 can view stored offers over a webbrowser, mobile phone, or other appropriate device, and select an offerto be sent to their mobile phone. In one embodiment, the stored offersare stored in the database tier 523. The consumer request to take anaction on a stored offer is received through the gateway tier 521 androuted to the application server 522(a). The application server 522(a)then retrieves the requested coupon from the database tier 523.

At step 9(2), a selected offer is pushed out to the user. In the exampleillustrated in FIG. 9, the offer is pushed out to the consumer 501through the telecommunication gateway 521(a) and a telecommunicationnetwork 502 to a suitable portable consumer device in the consumer'spossession. Just as with any other offer pushed out to a consumer 501,it is possible to push out offers to a wide variety of devices. After anoffer is received by the consumer, 501, the consumer 501 can redeem theoffer or take any other appropriate action.

6. Event Services

FIG. 10 illustrates the dataflow for a events service according to oneembodiment.

An events service provides many functions that may be useful tomerchants 503 or other users hosting events for consumers 501. Forexample, attendees of an event can be asked to vote on a particularissue, polled for their opinion, solicited for donations, bid on itemsin an auction, or simply registered at an event.

FIG. 10 illustrates dataflows that may be used according to oneembodiment to push out requests and receive responses for various eventsservices. FIG. 10 also illustrates dataflows that may be used to receiveregistration requests from users/consumers 501 for events.

Dataflow 10(1) illustrates a pathway taken by text requests and textresponses for events applications that push out requests tousers/consumers 501 and then receive responses from the users/consumers501. Requests that are sent via SMS text message start off at theapplication server 522(a), travel through the telecommunication gateway521(a) to a telecommunication network 502. The telecommunication network502 then delivers the request to users/consumers 501. When a userresponds to a request, the response makes its way back to theapplication server 522(a) by retracing the steps of the originaloutbound message. Just as with the coupon/offer applications previouslydiscussed, an events services request and response can also use otherdelivery mechanisms, such as e-mail, phone call, etc.

Dataflow 10(2) shows event registration services. This service can beused by consumers 501 to register or enroll in an event or service. Inthe example dataflow shown in FIG. 10, the consumer 501 uses a webapplication, such as a web browser, to send a registration request tothe application server 522(a). Although not shown in FIG. 10, asuccessful request can then be stored somewhere within the database tier523. When the consumer 501 arrives at the registered event, theconsumer's registration can be confirmed by sending a request to theapplication server 522(a) to verify that the appropriate registrationrecord exists in the database tier 523. Other variations of this basicmodel can also be implemented using the gateway service platform 520.

7. Card Alert Services

FIG. 11 illustrates the dataflow for a card alert service according toone embodiment. U.S. patent application Ser. No. 11/962,836, describinga customized payment transaction notification application, can also bereferenced for additional information on various card alert services.

A card alert can notify a cardholder of card activity. For example,alerts can be generated for purchases, ATM withdrawals, e-commercetransactions, foreign transaction, or other similar events.

A notification can be sent to any suitable device that can receivealerts and can provide such alerts to the consumer. Examples ofnotification devices include computers, cellular or mobile phones, wiredtelephones, personal digital assistants (PDAs), pagers, and the like.The notification device may be in any suitable form (e.g., suitablenotification devices can be hand-held and compact so that they can fitinto a consumer's wallet and/or pocket).

In some embodiments, the notification device and a portable consumerdevice can be embodied by the same device. For example, a wireless phonemay function as both portable consumer device that can be used to payfor goods or services, and a notification device to notify the consumerif activity associated with the wireless phone, or an account numberassociated with the wireless phone, is being conducted.

If the notification device is a phone, it may comprise a processor, anda computer readable medium coupled to the processor. The computerreadable medium comprises code for receiving an alert, wherein the alertindicates that the transaction is occurring, where the alert is sent tothe consumer according to a time or communication mode previouslyspecified by the consumer using an interface that allows the consumer tospecify the time and communication mode for receiving the alert.

Before a consumer can receive alerts, the consumer can register with thealert system. Information can be received using an interface that allowsthe user to specify the time and communication mode for receiving analert when a transaction is occurring with respect to a portableconsumer device associated with the consumer. The information includesthe communication mode or time in which the consumer wants to benotified.

In some embodiments, a consumer may customize the alert trigger (e.g.,only notify the consumer if the transaction that is occurring is greaterthan $5000 in value), time of the alert (e.g., from 9 a.m. to 5 p.m.),communication mode (e.g., e-mail, telephone, SMS), and/or contact (e.g.,wireless e-mail address, work e-mail address, spouse's cellular phone,home phone). The consumer may use an interface such as a Web interfaceto indicate how and/or when the consumer is to be alerted when theconsumer's portable consumer device or account number associated withthe portable consumer device is used. In embodiments of the invention,the consumer can specify whether he wants alerts set separately for eachaccount number and/or portable consumer device that he has. He can alsospecify that any alerts that are provided by provided at the same timeand under the same conditions across all accounts or portable consumerdevices associated with the consumer.

Illustratively, the consumer can visit a web site that allows theconsumer to customize the way in which he is alerted when his creditcard is being used. Using a web interface such as a web page, theconsumer may indicate that he wants to be notified by phone if hiscredit card or credit card account number is being used between 10 p.m.and 6 a.m. to conduct a transaction of any amount, since he will mostlikely be at home and sleeping during this time. Using the web page, theconsumer may also specify that the consumer wants to be notified of anyaccount or device activity via e-mail and a mobile phone during the hourof 6:00 a.m. and 10 p.m, only if the transaction amount if greater than$500. Thus, after the consumer provides this customization information,if a $5000 credit card transaction is conducted at 2 a.m. using theconsumer's credit card, a payment processing organization and/or issuermay then provide an alert to the consumer by calling the consumer on theconsumer's home telephone. The consumer may thereafter contact thepayment processing organization and/or the issuer to take appropriateaction. For example, the consumer may prevent the transaction fromtaking place by not authorizing the transaction. Alternatively, if a$5000 transaction is being conducted at 10 a.m. using the consumer'scredit card or credit card account number, the payment processingorganization and/or the issuer of the credit card may notify theconsumer by providing an alert to his e-mail device and his mobilephone.

For simplicity of illustration, one portable consumer device, oneconsumer, one issuer, one notification device, one client computer, oneaggregator, etc. is shown. It is understood however, that embodiments ofthe invention may include multiple portable consumer devices, consumers,issuers, notification devices, client computers, aggregators, etc

FIG. 11 illustrates the data flow that a card activity alert service mayuse to implement its service.

At step 11(1), consumer's 501 card is used to conduct a transaction witha merchant 503. This transaction may occur at the merchant's 503 store,over the internet, or via any other suitable means. In a typicaltransaction a consumer 501 may use the portable consumer device to makea purchase via a payment processing system 530. For example, theconsumer may use a portable consumer device, such as a credit card, topay $5000 for a flat screen television.

At step 11(2), once the consumer 501 uses the portable consumer device(e.g., swipes his credit card at a merchant), an authorization requestmessage passes to the payment processing system 530 from the merchant503. The payment processing system 530 then checks to see if thecharacteristics of the transaction that has been made with the portableconsumer device matches a condition (e.g., notification event trigger)under which a consumer wants to be alerted. In the embodimentillustrated in FIG. 11, this check is made with the issuer 550 of theconsumer's 501 portable consumer device.

As discussed above, there are a number of examples of notification eventtriggers. Examples of notification event triggers include the following:a transaction is over a certain amount of money (e.g. over $5000); anytransaction conducted with a particular portable consumer device; aspending threshold (e.g., a daily or monthly spending limit) has beenreached for a particular portable consumer device; a transaction is madeoutside a particular geographic location (e.g., outside the country thatthe consumer resides in); a risky transaction is being conducted(“risky” may be predefined by the consumer and/or the issuer), atransaction is made without the physical portable consumer device (e.g.,Internet, mail, or telephone order); a cash transaction or withdrawal;an online account has been accessed; a person has used the portableconsumer device to enter a certain location (e.g., a secure area, abusiness after-hours); a payment is due within a certain amount of time;a payment is overdue; a child or spouse has conducted a transaction; abalance on the portable consumer device is exceeded; a particular typeof transaction is being conducted (e.g., purchases for airline tickets,lodging, auto rental, restaurants, medical, etc.), etc. Thus, is systemis flexible enough to allow for many types of notification eventtriggers.

If there is no notification event trigger, then the notification processends. If there is a notification event trigger, the payment processingsystem sends the trigger information to the application server 522(a) inthe gateway service platform 520 as illustrated at step 11(3). Theapplication server 522(a) may check the SQL DB Server 523(a) to see how(or even if) the consumer 501 would like to be notified about thetransaction. If the consumer 501 does not want to be alerted about thisparticular type of transaction, the notification process ends.

If the consumer 501 would like to be notified about this particular typeof transaction, then an alert is then sent to the consumer 501 via thecommunication mode (e.g., via a specific communication channel)specified by the consumer 501. Examples of communication modes includevoice, mobile, SMS, e-mail, instant message, etc. In the embodimentillustrated in FIG. 11, an alert is sent to the consumer 501 via a textmessage that passes through the telecommunication gateway 521(a).

As noted above, consumer 501 may specify one or more communication modeper notification event trigger. For example, a consumer 501 may want tobe notified when a purchase is made that is over $5000 by mobile phoneand e-mail. In addition, a consumer 501 may specify one or more contactsfor each communication mode. For example, a consumer 501 can havemultiple mobile numbers (e.g., the consumer's personal mobile phone,work mobile phone, spouse's mobile phone number), multiple phone numbers(e.g., home phone, work phone), multiple SMS addresses (e.g., mobilephone, PDA, secretary's PDA), or multiple e-mail addresses (e.g., worke-mail, personal e-mail), etc. A consumer 501 may also customize thetime that he wants to receive each or all alerts. For example, theconsumer 501 may want to be notified immediately of the transaction,only during certain hours (e.g., between 9 a.m. and 5 p.m.), may specifydifferent communication modes for different times of the day or types oftransactions, or may choose not to be notified during certain hours(e.g., between 1 a.m. and 6 a.m.).

A consumer 501 can specify that he wants to receive a notification ifhis portable consumer device is used for a transaction over a certainamount of money (e.g., over $5000), via his work phone number andspouse's e-mail if it is during the day, and by SMS and home phone ifthe transaction occurs on the evening or weekend.

A consumer 501 may also want the alert to be escalated if the alert wasnot received. An alert may not be received if it could not be delivered(e.g., the mobile phone network was down or the consumer's number hasbeen de-listed), or the consumer does not acknowledge the alert messagewithin a certain time (e.g., respond to the message, listen to thevoicemail, or open the SMS message or e-mail). A status messageregarding whether or not a consumer has received the alert can be sentto the application server 522(a) in the SQL DB Server 523(a). Theapplication server 522(a) evaluates whether or not the alert should beescalated (e.g., whether the alert was received and whether the consumerhas specified that he wants the alert to be escalated). If the alert wasnot received, then the application server 522(a) can retry the samecommunication mode or try a different communication mode based on theconsumer preference or default settings. For example, a consumer mayhave an alert set for a purchase made out of the country in which heresides. He may want the alert be sent to his PDA that he generallycarries with him. However, if he does not receive the message on his PDAeither because the PDA service is down or he does not have it with him,he can specify that the alert then be sent to a different contact or toeach of his other contacts until the system knows that he has receivedthe alert.

The application server 522(a) may also include timers to send statusmessages so that the consumer 501 knows whether or not the portableconsumer device has been used for a transaction. For example, a consumer501 may want a timer that alerts him daily at 7 a.m. that he usedportable consumer device twice the day before or for certain types ofpurchases made with the portable consumer device.

Further, the consumer 501 may want to be alerted if the portableconsumer device is used to access a certain location. This can becharacterized as an access transaction. For example, a portable consumerdevice can be an access device to gain entrance to a building or otherlocation. An employee may enter a particular business after-hours orenter a secure area of that business. The consumer may want to receivean alert that the employee has used the portable consumer device toenter the secure area. For example, if Joe Employee enters the secureserver room after business hours, the consumer may receive an SMSmessage on his mobile phone that says “Joe Employee has entered securearea A (the server room).”

The notification sent to the consumer 501 may also pass through anaggregator before being delivered to a consumer. The aggregator may bean entity or organization that receives and transmits messages to aphone, e-mail account, etc. In some cases, wireless telephone companiesmay be considered aggregators.

8. Balance Alert Services I

FIG. 12 illustrates the dataflow for a card alert service according toone embodiment. U.S. patent application Ser. No. 11/963,736, describinga real-time balance update application, can also be referenced foradditional information on other balance alert services.

A balance alert is in many ways similar to the activity alerts describedabove. A notification with dynamic data, such as a balance alert, can betriggered when the consumer requests the notification or when theconsumer uses the portable consumer device. For example, balance alertscan be triggered off of IPS 531 activity or DPS 532 activity. Theconsumer can also have notifications automatically sent to thenotification device on a periodic basis. Once the notification istriggered, dynamic data is retrieved and delivered to the notificationdevice if the consumer is enrolled to receive the notification. Anexemplary embodiment of a notification is a real-time balance update.The real-time balance update is a communication to notify consumer ofthe funds available (balance) on portable consumer device after the lasttransaction is accounted for. The balances may include account balancessuch as credit card account balances, stored value account balances,rewards balances, checking account balances, savings account balances,investment account balances, brokerage account balances, and othersuitable account balances.

Certain embodiments of the invention may provide one or more technicaladvantages to issuers and consumers. One advantage to a consumer may beknowing their current balance or rewards available on their card withouthaving to contact the issuer which could save time and could save theconsumer money. Another advantage to a consumer may be that the consumercan request the current balance left on their card so that they candetermine whether they have sufficient funds or credit to make apurchase or complete a transaction. An advantage to an issuer may bethat automatic notifications are sent to consumers and issuer does nothave to provide notifications by other means.

Similar to the activity alert service, the balance alert service can useany suitable notification device and means of notification. For example,suitable notification devices can be hand-held and compact so that theycan fit into a consumer's wallet and/or pocket (e.g., pocket-sized).Some examples of notification device include desktop or laptopcomputers, cellular phones (e.g., as shown in FIG. 3), personal digitalassistants (PDAs), pagers, payment cards, security cards, access cards,smart media, transponders, and the like. In some embodiments,notification device and portable consumer device are embodied in thesame device. Some examples of suitable notifications includes a phonecall, a voice message, a voicemail message, a short message service(SMS) message e.g. a text message, an instant messaging (IM) message, oran email message, or a periodically updated display on a device.

A balance alert may retrieve enrollment information with triggerinformation from a notification database using a database server.Notification server confirms that consumer is enrolled to receive thenotification triggered based on the trigger information. Notificationserver retrieves the dynamic data from issuer or other suitable entityand sends the notification with the dynamic data through gateway toaggregator. Aggregator collects notifications according to enrollmentinformation and forwards the notifications to notification device. Ifthe notification triggered is associated with dynamic balance data,dynamic balance module processes the notification. If the notificationtriggered is associated with dynamic rewards data, dynamic rewardsmodule processes the notification.

At step 12(1), consumer's 501 card is used to conduct a transaction witha merchant 503. This transaction may occur at the merchant's 503 store,over the internet, or via any other suitable means. In a typicaltransaction a consumer 501 may use the portable consumer device to makea purchase via a payment processing system 530.

At step 12(2), once the consumer 501 uses the portable consumer device(e.g., swipes his credit card at a merchant), an authorization requestmessage passes to the payment processing system 530 from the merchant503. After the transaction is authorized, the payment processing system530 checks the current value of any dynamic data that is to be used inthe balance alert. In the embodiment illustrated in FIG. 12, this checkis made with the issuer 550 of the consumer's 501 portable consumerdevice.

The payment processing system 530 then sends a request to generate analert using the dynamic information to the application server 522(a) inthe gateway service platform 520 as illustrated at step 12(3). Theapplication server 522(a) may check the SQL DB Server 523(a) to see how(or even if) the consumer 501 would like to be notified.

Just as with the card activity alerts described above, there are manydifferent ways that the balance alert can be pushed out the consumer501.

9. Balance Alert Services II

FIG. 13 illustrates the dataflow for a card alert service according toone embodiment. In particular, FIG. 13 illustrates an example of thedataflow used to push out a balance alert at the request of a consumer.

At step 13(1), a consumer 501 sends text message to application server522(a) requesting their balance. As discussed in reference to many othergateway service platform services, this request passes through theappropriate networks and gateways to reach the application server522(a). Once the request is received, the application server 522(a)validates the request. For example, the application server 522(a) mayverify that the request was received from mobile phone associated with avalid account. The application server 522(a) may also lookup anyadditional information necessary to complete the request. For example,the application server 522(a) may lookup the account number associatedwith the portable consumer device that sent the request if the accountnumber was not included in the request. Once the application server522(a) has all of the necessary information, the balance request can bepassed onto a payment processing system 530 or a subcomponent thereofsuch as IPS 531.

At step 13(2) the payment processing system 530 sends a request to theissuer 550 of the account to get the card balance of the account

At step 13(3) a balance alert is sent to the gateway service platform520, and the gateway service platform 520 forwards this alert to theconsumer 501. Just as with other alert examples described above, thereare many different ways that the balance alert can be pushed out theconsumer 501.

10. Balance Alert Services III

FIG. 14 illustrates the dataflow for a card alert service according toone embodiment. In particular, FIG. 14 illustrates an example of thedataflow used to push out a balance alert on debit or prepaid cardactivity.

At step 14(1), consumer's 501 card is used to conduct a transaction witha merchant 503. This transaction may occur at the merchant's 503 store,over the internet, or via any other suitable means. In a typicaltransaction a consumer 501 may use the portable consumer device to makea purchase via a payment processing system 530.

At step 14(2), once the consumer 501 uses the portable consumer device(e.g., swipes his credit card at a merchant), an authorization requestmessage passes to the payment processing system 530 from the merchant503. In this example, the request is sent to DPS 532 and the accountused to conduct the transaction either has the current prepaid balance,or the money is collected by DPS the issuer 550. After the transactionis authorized, the DPS 532 checks the current value of any dynamic datathat is to be used in the balance alert. In the embodiment illustratedin FIG. 14, the DPS does not need to conduct any further checks to findthe necessary dynamic data.

At step 14(3) DPS 532 generates an alert to the gateway service platform520, which is delivered to the consumer 501. Just as with other alertexamples described above, there are many different ways that the balancealert can be pushed out the consumer 501.

10. ATM Locator Service

FIG. 15 illustrates the dataflow for a ATM Locator service according toone embodiment.

At step 15(1), the consumer 501 submits a request for the location of anATM to a third party location determining service 570. The request canbe made over the internet using a computer or a portable consumerdevice, and the response can be received on the same device or on adifferent device. Consumer 501 may provide an address, zip code, mobilenumber, or other information that can be used to help locate theconsumer 501.

The location of the consumer 501 can be determined in any suitablemanner. For example, in one embodiment, a consumer 501 may use an ATMlocator on a website (e.g., an issuer's website) to search for one ormore available ATMs in a particular location. Alternatively, the currentlocation of the consumer 501 can be determined automatically using aglobal positioning system (GPS) element on the consumer's mobile phone,in the consumer's car etc. Other location based methods, including thedetermination of mobile phone signal strength can be used to determinethe consumer's location. Yet another location based determination methodinvolves the use of a consumer's credit and debit cards. For instance,when a consumer 501 purchases an item from a particular merchant, aserver computer in a payment processing system can determine thelocation of that merchant, and hence the location of the consumer.

Once the consumer's location is determined, a response can be sent tothe consumer 501. At step 15(2), an ATM location, as computed by alocation determining entity is sent to the gateway service platform 520via a “sendSMS web service” exposed by the gateway service platform 520.Typically, client and server side certificates are used to help securethis communication between a third-party, such as a third party locationdetermining service 570, and the gateway service platform 520. Thiscommunication is received by the application server 522(a).

At step 15(3), an alert with the ATM location is sent to the consumer501. Just as with other alert examples described above, there are manydifferent ways that an alert can be pushed out the consumer 501.

The above ATM location service is a good example of how 3^(rd) partyservices can leverage the gateway service platform 520 to sendinformation out of to consumers 501. One skilled in the art willrecognize that the ATM locator service could have alternatively beenimplemented within the application server 522(a), as the previousservice examples were described.

11. IP Terminal Service

FIG. 16 illustrates the dataflow for an IP Terminal service according toone embodiment. U.S. patent application Ser. No. 11/536,296 describing amobile transit fare payment application and U.S. patent application Ser.No. 12/022,060, describing a mobile device payment application, describeother payment applications that may use similar data flows as an IPterminal.

IP terminals can be embodied as access devices that can be used toprocess payments for purchase transactions. IP terminals are generallycapable of communicating over the internet, telecommunication networks,or other similar networks. IP terminals are useful in areas where directaccess to the closed network maintained by third-party paymentprocessors is not easily available, but other open networks are easilyavailable. For example, this situation exists in many places such asIndia and China.

The data flow for a standard (non-IP terminal) payment transaction isdescribed later in this disclosure. As illustrated in FIG. 16, thegateway service platform 520 can help to facilitate payment transactionsconducted using IP terminals since the gateway service platform 520 candirectly receive payment authorization requests from the IP terminalsused by merchants 503. As illustrated by data flow 16(1), paymentauthorization requests sent by IP terminals may be received over theinternet 510 or from a telecommunication network 502. Differentembodiments of IP terminals may also use other appropriate networks.Once the application server 522(a) in the gateway service platform 520receives this authorization request, the request can be forwarded to apayment processing system 530 and handled just like any other paymentrequest. The response to the payment request can then be sent backthrough the gateway service platform 520 to the IP terminal of themerchant 503.

12. Passive Enrollment Service

FIG. 17 illustrates the dataflow for a passive enrollment serviceaccording to one embodiment.

Typically enrollment into any service offered by a gateway serviceplatform can happen in a number of ways. According to one method,consumers may enroll themselves into a service using the web or a mobiledevice. This is an example of an active enrollment method.

Another enrollment method is for the gateway service platform is wherean issuer enrolls its users for services offered by the gateway serviceplatform without the users taking any affirmative actions themselves.This is referred to as passive enrollment, and an example of a dataflowused during a passive enrollment process is illustrated in FIG. 17.

At step 17(1), an issuer 550 provides an enrollment file for a service.The enrollment file may contain information for all of the issuer'susers, or it may only contain a list of enrollment changes. Thisenrollment file may be entered into the gateway service platformmanually, or the file may be electronically parsed and processed.

At step 17(2), the enrollment file is validated by the applicationserver 522(a). If the file does not contain any errors, the entries inthe file are stored within the database tier 523. The issuer 550 can benotified of any errors contained in the enrollment file.

At step 17(3), user 501 can complete the enrollment process via SMSactivation or Web activation. In some embodiments user completion maynot be necessary. However, user confirmation can serve a securitypurpose and help to further validate the information supplied by theissuer. Once registration is complete, contact information of theconsumer can be shared with other systems that require the information.

13. Exemplary Integrated Services

One of the benefits offered by embodiments of the present invention isthe ability to more quickly integrate various features of services toprovide new functionality for users. Integration becomes easier becauseservices and applications can easily share resources, such as data indatabases, share connections to networks, such as the internet orpayment processing networks, and communicate with each other withouthaving to navigate through firewalls, routers, and other pieces of basicinfrastructure that might exist between implementations of differentservices. Another advantage of integrating services and applications atthe gateway service layer is that since the gateway service layer cancommunicate with many different issuers, merchants, and other parties,the gateway service layer is in a good position to combine data frommany different sources that might not otherwise be easily aggregated.For example, if a consumer has multiple credit cards with differentissuers, services implemented and integrated with each other at thegateway service layer can access all of this data and provide a greaterrange of services. There are many possible ways in which services andapplications, such as the ones described above, can be integrated witheach other to quickly provide new functionality to services withouthaving to re-implement large sections of existing services.

In one example of an integrated service, one skilled in the art couldintegrate a challenge-response service with a P2P service. Such anintegrated service would enable a payor to authorize a P2P transactionby responding with a ZIP code, or other piece of personal accountinformation, rather than an established PIN.

Another example of an integrated service would be the integration of acouponing/offer service with a balance notification service. The balancemonitoring modules of a balance notification service can be used totrigger when various coupons or other offers are made available tousers. Similarly, the triggers associated with a card activity servicecould also be integrated with a couponing service.

In yet another example, activity on a first credit card held by a firstissuer can trigger a coupon or offer available through a second creditcard held by a different issuer. Not only are aspects of differentservices combined (activity alerts and couponing), but the features areable to span multiple consumer accounts held by different issuers.Similarly, merchants and issuers may be able to take advantage of theaggregation of data at the gateway service platform for other services.

The number of different ways that services and applications can beintegrated with each other is nearly endless. The above combinationexamples are meant to be illustrative, and not exhaustive. It would benearly impossible to describe every permutation of how differenceservices can be integrated or combined. Additionally, although notexplicit above, it is clear that more than two services may be combinedto implement new features. One skilled in the art will recognize thatany possible integration or combination of services will be easier toimplement using the gateway service platform than prior serviceimplementation techniques, such as the Silo Method.

II. Exemplary Payment Processing System A. Payment Processing System

FIG. 18 shows various components and systems that are typically used toconduct a payment transaction using a payment processing system. Many ofthese components have been briefly described earlier in this disclosureand are more fully described below. As previously described, the gatewayservice platform and the services and applications that it enables areoften integrated with a payment processing network (sometimes referredto as a payment processing system) to provide various pieces offunctionality to users, merchants, and other relevant parties. Thedescription of a payment processing system as described below helps tofurther put into context the various modules, actors, and othercomponents of a payment processing system so that how such as systemmight interact with a gateway service platform becomes more readilyapparent. Other payment processing systems, according to otherembodiments of the invention, may include more or less components thanare shown in FIG. 18.

The system 20 shown in FIG. 18 includes a merchant 22 and an acquirer 24associated with the merchant 22. In a typical payment transaction, aconsumer 30 may purchase goods or services at the merchant 22 using aportable consumer device 32. The merchant 22 could be a physical brickand mortar merchant or an e-merchant. The acquirer 24 can communicatewith an issuer 28 via a payment processing system 26. The merchant 22could alternatively be connected directly to the payment processingsystem 26. The consumer may interact with the payment processing system26 and the merchant through an access device 34.

As used herein, an “acquirer” is typically a business entity, e.g., acommercial bank that has a business relationship with a particularmerchant or an ATM. An “issuer” is typically a business entity (e.g., abank) which issues a portable consumer device such as a credit or debitcard to a consumer. Some entities can perform both issuer and acquirerfunctions. Embodiments of the invention encompass such single entityissuer-acquirers.

The consumer 30 may be an individual, or an organization such as abusiness that is capable of purchasing goods or services. In otherembodiments, the consumer 30 may simply be a person who wants to conductsome other type of transaction such as a money transfer transaction or atransaction at an ATM.

The portable consumer device 32 may be in any suitable form. Forexample, suitable portable consumer devices can be hand-held and compactso that they can fit into a consumer's wallet and/or pocket (e.g.,pocket-sized). They may include smart cards, ordinary credit or debitcards (with a magnetic strip and without a microprocessor), keychaindevices (such as the Speedpass™ commercially available from Exxon-MobilCorp.), etc. Other examples of portable consumer devices includecellular phones, personal digital assistants (PDAs), pagers, paymentcards, security cards, access cards, smart media, transponders, and thelike. The portable consumer devices can also be debit devices (e.g., adebit card), credit devices (e.g., a credit card), or stored valuedevices (e.g., a stored value card). According to some embodiments, acomputer or other similar device can be used in place of a portableconsumer device to achieve the same functionality as the portableconsumer device.

The merchant 22 may also have, or may receive communications from, anaccess device 34 that can interact with the portable consumer device 32.The access devices according to embodiments of the invention can be inany suitable form.

Examples of access devices include point of sale (POS) devices, cellularphones, PDAs, personal computers (PCs), tablet PCs, handheld specializedreaders, set-top boxes, electronic cash registers (ECRs), automatedteller machines (ATMs), virtual cash registers (VCRs), kiosks, securitysystems, access systems, and the like.

If the access device 34 is a point of sale terminal, any suitable pointof sale terminal may be used including card readers. As describedearlier, some access devices may interact with the payment processingnetwork via the gateway service platform over a network such as theinternet. The card readers may include any suitable contact orcontactless mode of operation. For example, exemplary card readers caninclude RF (radio frequency) antennas, magnetic stripe readers, etc. tointeract with the portable consumer devices 32.

The access device 34 may also be a wireless phone. In one embodiment,the portable consumer device 32 and the access device are the samedevice. For example, a consumer may use a wireless to phone to selectitems to buy through a browser.

When the access device 34 is a personal computer, the interaction of theportable consumer devices 32 may be achieved via the consumer 30 oranother person entering the credit card information into an application(e.g. a browser) that was opened to purchase goods or services and thatconnects to a server of the merchant, e.g. through a web site. In oneembodiment, the personal computer may be at a checkout stand of a retailstore of the merchant, and the application may already be connected tothe merchant server.

Payment processing system 26 may include data processing subsystems,networks, and operations used to support and deliver authorizationservices, exception file services, and clearing and settlement services.An exemplary payment processing system may include VisaNet™. Paymentprocessing systems such as VisaNet™ are able to process credit cardtransactions, debit card transactions, and other types of commercialtransactions. VisaNet™, in particular, includes an IPS system, such asthe Visa Integrated Payments system, which processes authorizationrequests and a Base II system which performs clearing and settlementservices.

The payment processing system 26 may include a server computer. A servercomputer is typically a powerful computer or cluster of computers. Forexample, the server computer can be a large mainframe, a minicomputercluster, or a group of servers functioning as a unit. In one example,the server computer may be a database server coupled to a Web server.The payment processing system 26 may use any suitable wired or wirelessnetwork, including the Internet.

The issuer 28 may be a bank or other organization that may have anaccount associated with the consumer 30.

Embodiments of the invention are not limited to the above-describedembodiments. For example, although separate functional blocks are shownfor an issuer, payment processing system, and acquirer, some entitiesperform all or any suitable combination of these functions and may beincluded in embodiments of invention. Additional components may also beincluded in embodiments of the invention.

In a typical purchase transaction, the consumer 30 purchases a good orservice at the merchant 22 using a portable consumer device 32 such as acredit card. An authorization request message is then forwarded to theacquirer 24. After receiving the authorization request message, theauthorization request message is then sent to the payment processingsystem 26. The payment processing system 26 then forwards theauthorization request message to the issuer 28 of the portable consumerdevice 32.

After the issuer 28 receives the authorization request message, theissuer 28 sends an authorization response message back to the paymentprocessing system 26 to indicate whether or not the current transactionis authorized (or not authorized). The transaction processing system 26then forwards the authorization response message back to the acquirer24. The acquirer 24 then sends the response message back to the merchant22.

After the merchant 22 receives the authorization response message, theaccess device 34 at the merchant 22 may then provide the authorizationresponse message for the consumer 30. The response message may bedisplayed by the POS terminal, or may be printed out on a receipt.

The system 20 in FIG. 18 typically resides on a closed network that isnot accessible to the general public. For example, it is typically notpossible for a consumer 30 or an issuer 28 to be able to connect to thesystem through the internet. A specialized connection normally needs tobe configured for each entity wishing to connect to the system.Additionally, the messages that are exchanged between all of theentities in the system 20 typically are exchanged on the same closednetwork.

B. Consumer Devices and Computer Apparatuses

FIGS. 19( a)-19(b) show block diagrams of computer devices andsubsystems that may be present in computer apparatuses in systemsaccording to embodiments of the invention. For example, the computerdevices and subsystems described below may be the same as consumerdevices 201 illustrated in FIG. 2 and used by User/Consumer 501 in FIGS.4-17. As previously described, many of the services and applications useconsumer devices and portable consumer devices to gather informationfrom and communicate with consumers.

The consumer device 32 may be in any suitable form. For example,suitable consumer devices can be hand-held and compact so that they canfit into a consumer's wallet and/or pocket (e.g., pocket-sized). Theymay include smart cards, ordinary credit or debit cards (with a magneticstrip and without a microprocessor), keychain devices (such as theSpeedpass™ commercially available from Exxon-Mobil Corp.), etc. Otherexamples of consumer devices include cellular phones (e.g., the phone 34described above), personal digital assistants (PDAs), pagers, paymentcards, security cards, access cards, smart media, transponders, and thelike. The consumer devices can also be debit devices (e.g., a debitcard), credit devices (e.g., a credit card), or stored value devices(e.g., a stored value card). Other consumer devices may include personalcomputers, laptops, or other devices capable of communicating over theinternet.

An exemplary consumer device 32′ in the form of a phone may comprise acomputer readable medium and a body as shown in FIG. 19A. (FIG. 19Ashows a number of components, and the portable consumer devicesaccording to embodiments of the invention may comprise any suitablecombination or subset of such components.) The computer readable medium32(b) may be present within the body 32(h), or may be detachable fromit. The body 32(h) may be in the form a plastic substrate, housing, orother structure. The computer readable medium 32(b) may be a memory thatstores data and may be in any suitable form including a magnetic stripe,a memory chip, uniquely derived keys (such as those described above),encryption algorithms, etc. The memory also preferably storesinformation such as financial information, transit information (e.g., asin a subway or train pass), access information (e.g., as in accessbadges), etc. Financial information may include information such as bankaccount information, bank identification number (BIN), credit or debitcard number information, account balance information, expiration date,consumer information such as name, date of birth, etc. Any of thisinformation may be transmitted by the portable consumer device 32.

Information in the memory may also be in the form of data tracks thatare traditionally associated with credits cards. Such tracks includeTrack 1 and Track 2. Track 1 (“International Air Transport Association”)stores more information than Track 2, and contains the cardholder's nameas well as account number and other discretionary data. This track issometimes used by the airlines when securing reservations with a creditcard. Track 2 (“American Banking Association”) is currently mostcommonly used. This is the track that is read by ATMs and credit cardcheckers. The ABA (American Banking Association) designed thespecifications of this track and all world banks must abide by it. Itcontains the cardholder's account, encrypted PIN, plus otherdiscretionary data.

The consumer device 32 may further include a contactless element 32(g),which is typically implemented in the form of a semiconductor chip (orother data storage element) with an associated wireless transfer (e.g.,data transmission) element, such as an antenna. Contactless element32(g) is associated with (e.g., embedded within) portable consumerdevice 32 and data or control instructions transmitted via a cellularnetwork may be applied to contactless element 32(g) by means of acontactless element interface (not shown). The contactless elementinterface functions to permit the exchange of data and/or controlinstructions between the mobile device circuitry (and hence the cellularnetwork) and an optional contactless element 32(g).

Contactless element 32(g) is capable of transferring and receiving datausing a near field communications (“NFC”) capability (or near fieldcommunications medium) typically in accordance with a standardizedprotocol or data transfer mechanism (e.g., ISO 14443/NFC). Near fieldcommunications capability is a short-range communications capability,such as RFID, Bluetooth™, infra-red, or other data transfer capabilitythat can be used to exchange data between the portable consumer device32 and an interrogation device. Thus, the portable consumer device 32 iscapable of communicating and transferring data and/or controlinstructions via both cellular network and near field communicationscapability.

The consumer device 32 may also include a processor 32(c) (e.g., amicroprocessor) for processing the functions of the consumer device 32and a display 32(d) to allow a consumer to see phone numbers and otherinformation and messages. The consumer device 32 may further includeinput elements 32(e) to allow a consumer to input information into thedevice, a speaker 32(f) to allow the consumer to hear voicecommunication, music, etc., and a microphone 32(i) to allow the consumerto transmit her voice through the consumer device 32. The consumerdevice 32 may also include an antenna 32(a) for wireless data transfer(e.g., data transmission).

If the consumer device is in the form of a debit, credit, or smartcard,the consumer device may also optionally have features such as magneticstrips. Such devices can operate in either a contact or contactlessmode.

An example of a consumer device 32″ in the form of a card is shown inFIG. 19( b). FIG. 19( b) shows a plastic substrate 32(m). A contactlesselement 32(o) for interfacing with an access device 34 may be present onor embedded within the plastic substrate 32(m). Consumer information32(p) such as an account number, expiration date, and consumer name maybe printed or embossed on the card. Also, a magnetic stripe 32(n) mayalso be on the plastic substrate 32(m).

As shown in FIG. 19( b), the consumer device 32″ may include both amagnetic stripe 32(n) and a contactless element 32(o). In otherembodiments, both the magnetic stripe 32(n) and the contactless element32(o) may be in the portable consumer device 32″. In other embodiments,either the magnetic stripe 32(n) or the contactless element 32(o) may bepresent in the portable consumer device 32″.

The various participants and elements in FIG. 18, as well as the variouscomponents and systems that comprise embodiments of the gateway serviceplatform, may operate one or more computer apparatuses to facilitate thefunctions described herein. Any of the elements in FIG. 18 may use anysuitable number of subsystems to facilitate the functions describedherein. Examples of such subsystems or components are shown in FIG. 20.The subsystems shown in FIG. 21 are interconnected via a system bus 775.Additional subsystems such as a printer 774, keyboard 778, fixed disk779 (or other memory comprising computer readable media), monitor 776,which is coupled to display adapter 782, and others are shown.Peripherals and input/output (I/O) devices, which couple to I/Ocontroller 771, can be connected to the computer system by any number ofmeans known in the art, such as serial port 777. For example, serialport 777 or external interface 781 can be used to connect the computerapparatus to a wide area network such as the Internet, a mouse inputdevice, or a scanner. The interconnection via system bus allows thecentral processor 773 to communicate with each subsystem and to controlthe execution of instructions from system memory 772 or the fixed disk779, as well as the exchange of information between subsystems. Thesystem memory 772 and/or the fixed disk 779 may embody a computerreadable medium.

Embodiments of the invention are not limited to the above-describedembodiments. For example, although separate functional blocks are shownfor an issuer, payment processing system, and acquirer, some entitiesperform (e.g., Discover, AMEX, etc.) all of these functions and may beincluded in embodiments of invention.

It should be understood that the present invention as described abovecan be implemented in the form of control logic using computer softwarein a modular or integrated manner. Based on the disclosure and teachingsprovided herein, a person of ordinary skill in the art will know andappreciate other ways and/or methods to implement the present inventionusing hardware and a combination of hardware and software

Any of the software components or functions described in thisapplication, may be implemented as software code to be executed by aprocessor using any suitable computer language such as, for example,Java, C++or Perl using, for example, conventional or object-orientedtechniques. The software code may be stored as a series of instructions,or commands on a computer readable medium, such as a random accessmemory (RAM), a read only memory (ROM), a magnetic medium such as ahard-drive or a floppy disk, or an optical medium such as a CD-ROM. Anysuch computer readable medium may reside on or within a singlecomputational apparatus, and may be present on or within differentcomputational apparatuses within a system or network.

The above description is illustrative and is not restrictive. Manyvariations of the invention will become apparent to those skilled in theart upon review of the disclosure. The scope of the invention should,therefore, be determined not with reference to the above description,but instead should be determined with reference to the pending claimsalong with their full scope or equivalents.

One or more features from any embodiment may be combined with one ormore features of any other embodiment without departing from the scopeof the invention.

A recitation of “a”, “an” or “the” is intended to mean “one or more”unless specifically indicated to the contrary.

All patents, patent applications, publications, and descriptionsmentioned above are herein incorporated by reference in their entiretyfor all purposes. None is admitted to be prior art.

1-21. (canceled)
 22. A method comprising: selecting, by a device, agateway amongst a plurality of gateways; sending a request, from thedevice to the selected gateway over an open network, to access aservice; wherein the request is sent to a service system provided by aserver computer, wherein the service system is one of a plurality ofservice systems communicatively coupled to the gateway, wherein theservice system is communicatively coupled to a payment processingsystem, wherein the service system is configured to provide one or moreof services related to an account held by a user, and wherein theservice system further comprises an application tier and is configuredto communicate with a shared database tier that is being shared amongstthe plurality of service systems, wherein the application tier containslogic used to provide one or more services related to the account heldby the user, and wherein the shared database tier stores informationused to provide the one or more services related to the account held bythe user; and receiving, at the device, a response from the servicesystem.
 23. The method of claim 22 wherein the device is a mobile deviceor a payment terminal device.
 24. The method of claim 22 wherein thedevice is operated by a consumer or a merchant.
 25. The method of claim22 further comprising: after selecting the gateway amongst the pluralityof gateways, determining that the gateway is non-responsive; andselecting another gateway amongst the plurality of gateways.
 26. Themethod of claim 22 wherein the device is configured to communicate withthe gateway before communicating with an acquirer.
 27. The method ofclaim 22 wherein the service includes an activity alert service, abalance notification service, a P2P or P2B service, an ATM locatorservice, offers and couponing service, event service, transit paymentservice, or IP terminal support service.
 28. A device comprising: aprocessor; and a non-transitory computer readable medium, coupled withthe processor, comprising code executable by the processor for:selecting a gateway amongst a plurality of gateways; sending a requestto the selected gateway over an open network, to access a service;wherein the request is sent to a service system provided by a servercomputer, wherein the service system is one of a plurality of servicesystems communicatively coupled to the gateway, wherein the servicesystem is communicatively coupled to a payment processing system,wherein the service system is configured to provide one or more ofservices related to an account held by a user, and wherein the servicesystem further comprises an application tier and is configured tocommunicate with a shared database tier that is being shared amongst theplurality of service systems, wherein the application tier containslogic used to provide one or more services related to the account heldby the user, and wherein the shared database tier stores informationused to provide the one or more services related to the account held bythe user; and receiving a response from the service system.
 29. Thedevice of claim 28 wherein the device is a mobile device or a paymentterminal device.
 30. The device of claim 28 wherein the non-transitorycomputer readable medium further comprises code executable by theprocessor for: after selecting the gateway amongst the plurality ofgateways, determining that the gateway is non-responsive; and selectinganother gateway amongst the plurality of gateways.
 31. The device ofclaim 28 wherein the device is configured to communicate with thegateway before communicating with an acquirer.
 32. The device of claim28 wherein the service includes an activity alert service, a balancenotification service, a P2P or P2B service, an ATM locator service,offers and couponing service, event service, transit payment service, orIP terminal support service.
 33. A method comprising: receiving, at aserver computer associated with a service system, a request via agateway from a device requesting access to a service; wherein theservice system is one of a plurality of service systems communicativelycoupled to the gateway, wherein the service system is configured toprovide one or more of services related to an account held by a user,and wherein the service system further comprises an application tier andis configured to communicate with a shared database tier that is beingshared amongst the plurality of service systems, wherein the applicationtier contains logic used to provide one or more services related to theaccount held by the user, and wherein the shared database tier storesinformation used to provide the one or more services related to theaccount held by the user; and sending a response to the device thatrequested access to the service.
 34. The method of claim 33 wherein theservice system is associated with a payment processing system.
 35. Themethod of claim 33 wherein the device is configured to communicate withthe gateway before communicating with an acquirer.
 36. The method ofclaim 33 wherein the service system is grouped into one or more servicesystem groupings and wherein the one or more service system groupingsare determined according to one or more open networks used to connectthe device to the gateway.
 37. The method of claim 36 wherein the one ormore service systems groupings include web services, terminal services,and mobile services.
 38. A server computer associated with a servicesystem comprising: a processor; and a non-transitory computer readablemedium, coupled with the processor, comprising code executable by theprocessor for: receiving a request via a gateway from a devicerequesting access to a service; wherein the service system is one of aplurality of service systems communicatively coupled to the gateway,wherein the service system is configured to provide one or more ofservices related to an account held by a user, and wherein the servicesystem further comprises an application tier and is configured tocommunicate with a shared database tier that is being shared amongst theplurality of service systems, wherein the application tier containslogic used to provide one or more services related to the account heldby the user, and wherein the shared database tier stores informationused to provide the one or more services related to the account held bythe user; and sending a response to the device that requested access tothe service.
 39. The server computer of claim 38 wherein the servicesystem is associated with a payment processing system.
 40. The servercomputer of claim 38 wherein the device is configured to communicatewith the gateway before communicating with an acquirer.
 41. The servercomputer of claim 38 wherein the service system is grouped into one ormore service system groupings and wherein the one or more service systemgroupings are determined according to one or more open networks used toconnect the device to the gateway.